home *** CD-ROM | disk | FTP | other *** search
- Date: Tue, 26 Jul 94 20:16 CDT
- From: ekl@sdf.lonestar.org (Evan K. Langlois)
- To: gem-list@world.std.com
- Subject: Re: GEM apps, in general
- Precedence: bulk
-
- ========================================================================
- It may well be a lot faster, but its hideously expensive and inefficient.
- The main window of my first real gem application was a scrolling CLI window,
- and I initially considered doing redraws by maintaining a blittable copy of
- ========================================================================
-
- Of course, for something like text, an offscreen bitmap is a horrible
- idea. But what about a graphics screen? No, not GEM-objects. Obviously,
- the display of a GEM IMG or XIMG file or similar file requires that you
- change the file to device dependant form and then blit it during redraws.
- Or you transform the IMG during redraw and slow it down. Either way,
- you are gonna back that window via blitting.
-
- Consider VDI calls. Or a Metafile. Should you save these in some
- command buffer and then call through the list (of indeterminate size)
- every time the window needs to be redrawn? What about scrolling?
- You'll have to clip to a small area and call through a list of VDI commands
- for every click of the arrow! If the user hold down the arrow button he'll
- quickly fall asleep!!
-
- Consider a graphics terminal .. not like IGS, but better, more efficient,
- with the AEs active and no hacks! It can't be done!
-
- I say it can't be done, meaning without moving logbase, making it NVDI
- specific or blitting things all over the place trying to use memory.sys
- in a color situation (the only legal way, but its slow and you need 2
- blit buffers plus teh screen!).
-
- I think there ARE places where a blit-buffer is of general use, and it
- would be nice to have a standard way of doing it that would work on
- more than one machine. Telling people they shouldn't do it is a bit
- short-sighted.
-
-